% !TEX root = main.tex

\section{Model-Driven Security}
\label{sec:mds}

This section starts by refining the concept of \mds from various definitions in the literature. 
It then synthesizes a generic schema, the \emph{Y-Model}, which is an incarnation of the concept and used to evaluate 
modeling and security analysis capabilities of various \mds methodologies later in \sect \ref{sec:evaluation}.

\subsection{Concept}
\label{sec:concept}

\begin{figure}[t] 
	\centering
	\includegraphics[width=\columnwidth]{./figures/mda-mds_v02}
	\caption{MDS: a specialization of MDA regarding security}
	\label{fig:mda-mds}
\end{figure}

In literature, several contributions \cite{sanchez:jucs-15-15,gartner:mds,citeulike:10644974,Basin:2011:DMS:1998441.1998443} provided tentative definitions for \emph{Model-Driven Security} (\mds). 

S\'anchez \etal \cite{sanchez:jucs-15-15} emphasized very early the de facto necessity of introducing models as primary artifacts for \mds. 
McDonald \cite{gartner:mds} promoted in 2007 the use of Domain-Specific Models (\textsc{Dsm}s) for each concern, either business or security, and introduced the idea of Separation of Concerns (SoC). 
Not longer after, Lang and Schreiner \cite{citeulike:10644974} introduced the idea of using models (\textsc{Dsm}s in particular) at each stage of the development, 
but more importantly the systematic use of transformations for generating code from these high-level abstraction in an automated way, to avoid error-prone human intervention. 
These transformations take care of the runtime security management and policy enforcement. 
More recently, Basin \etal \cite{Basin:2011:DMS:1998441.1998443} insisted on the importance of visual tools and automated transformations to generate appropriate code, 
which constitute the very core concepts of \textsc{Dsm}s. They also conveyed the strong idea that \mds is no more than a specialization of 
the \emph{Model-Driven Architecture} (\mda) \cite{omg/2003-06-01} with the systematic use of \textsc{Dsm}s, see \fig \ref{fig:mda-mds}.

% Characteristics
Although different points of view are expressed in the above contributions, they share common features that constitute significant characteristics of \mds: 
\emph{separating security from business concerns} at the very beginning of the development lifecycle to enable reusable and cleaner design; 
\emph{using \textsc{Dsm}s} for both concerns to benefit from associated advantages (adequate levels of abstraction closer to both concerns; 
concrete syntaxes with visual representations; automatic transformations enabling trustful code, among others); 
\emph{integrating security and business concerns} by means of model composition/weaving, using transformations, which enables analysis of security enforcement before generating low-level code; 
\emph{enforcing security at runtime} directly from the integrated model in an automated fashion; 
and finally \emph{assisting development with appropriate tools} at each step of the development.

From those common features, it is possible to propose a more accurate \mds definition that encompasses the previous ones:
\begin{quotation}
\textbf{Model-Driven Security} is a tool-supported model-driven approach that separates security concerns from business logic at early stage of the development lifecycle, 
specifies business and security models respectively with \textsc{Dsm}s, and manages the secure infrastructure generation directly from a composed model with as little human interference as possible.
\end{quotation}

% Outline: Y-Model as generic evolution criteria
\subsection{Y-Model: A Generic Evaluation Schema for MDS}
\label{sec:Y-model}

\begin{figure}[t] 
	\centering
	\includegraphics[width=\columnwidth]{./figures/Y-model}
	\caption{Y-Model: a generic evaluation schema for Model-Driven Security}
	\label{fig:y-model}
\end{figure}

Inspired from the well-known V-Model in software engineering, we propose a \emph{Y-Model} as a generic evaluation schema for \mds methodologies.
It is named so only because the model is shaped as the letter ``Y''.
Note that although other proposals, \eg \cite{Capretz:2005}, mentioned the term ``Y-Model'' in other research domains, our proposal is, 
to the best of our knowledge, the first one to mention this concept in the context of \mds.

The proposed Y-Model, as depicted in \fig \ref{fig:y-model}, is a fundamental concept model for \mds and fully integrates common \mds characteristics presented in \sect \ref{sec:concept}.
It bridges the semantic gap between high-level security concerns and their enforcement on system infrastructure \cite{vanWyk:2005:BGS:1092708.1092755}.
It illustrates the complete process of \mds as well as the general objective of \mds that the runtime infrastructure with security concerns enforced is
obtained from high-level requirements based on model-driven architecture.
The Y-Model is organized in three layers with a traceability feature throughout all these layers:

\subsubsection{Layer 1: Requirement Gathering}
\label{sec:Y-L1}

This top layer is the key to SoC: business logic is handled by software engineers and domain experts, which is organically separated from security concerns that are delegated to security experts. 

\subsubsection{Layer 2: Modeling \& Analysis}
\label{sec:Y-L2}

The second and middle layer deals with modeling and analysis tasks: each model, conforming to a different metamodel, is extracted independently from the requirements expressed at the previous layer. Since both are loosely coupled, each side can perform analysis tasks tailored to the domain at hand, in an agile fashion: from the verification
results, models are evolved and corrected until satisfactory ones are reached.

Both models are then composed, conforming to a \emph{composition metamodel}, to merge the abstractions of business and security. 
It can take several forms: profiling \uml-based business metamodels to integrate security information; 
building a mapping metamodel between both metamodels to link concepts from both sides; 
or creating a truly composed metamodel by merging the equivalent concepts from both sides. 
The possibilities are diverse, and we discuss later in \sect \ref{sec:evaluation} how each evaluated \mds methodology performs its own.
Once the composed model is obtained, integration verification can be performed to ensure enforcement of security properties, very similar to system integration testing. 

\subsubsection{Layer 3: Code Generation \& Testing}
\label{sec:Y-L3}

The bottom layer handles code-generation and testing from the composed
model. Two dimensions have to be taken care of: including platform-specific
information, and generating system infrastructure that actually enforces security.
For these purposes, transformation techniques inherited from \mde in general, and \mda in particular, can help reducing the technical
burden. \emph{Model-To-Model} (M2M) helps in this context for integrating platform-specific information seamlessly and it is still dealing with high-level models (similarly to \mda, this also requires models describing the different targeted platforms). \emph{Model-To-Text/Model-To-Code} (M2C) transformations allow generating code runnable on specific platforms from higher-level description models. In our context, this code integrates the runtime security enforcement mechanism to deliver a testable infrastructure. \emph{Model-To-Test} (M2T) transformations aim at generating tests directly from the model, similarly to the test-driven approach: tests are automatically built at the same time as the code to be tested is generated.


Using model transformations automates the task of generating code, enables reusability, and
increases confidence in the generated code since the transformations can be
written only once, and for all after the metamodels have reached stability. Therefore,
we evaluate in \sect \ref{sec:evaluation} how each \mds approach handles code and
test generation from the models manipulated at higher layers.

\subsubsection{Traceability}
\label{sec:Y-Traceability}

On the very right of \fig \ref{fig:y-model}, a bidirectional arrow labeled ``backward \& forward traceability'' spans over all three layers.
\emph{Backward traceability} helps locating design flaws on higher-level models when a counterexample is detected during the verification of lower-level models or the testing of system infrastructure.
While a design flaw is corrected on higher-level abstraction, the \emph{forward traceability} ideally helps propagating corresponding modifications throughout all the lower-level models or system infrastructure.

However, traceability is usually done manually in practice, since automating it is quite hard due to the semantic gaps between layers.
For example, the composed model integrates both business and security models, but also platform-specific information that makes difficult to trace back mistakes in the security
requirements. Discovering errors in Layer 3 is even worse, since there, security concerns can be distributed all over the generated code due to its low-level nature.

